This invention relates to software application development and more particularly to the development of a software application for controlling a device, such as a robot.
A software application for controlling a device is often written in a language that has been specially developed by a manufacturer of the device. Although the languages of different manufacturers may be based on the same high level language, such as the C programming language, each manufacturer's language typically has its own syntax and semantics. This is especially true in the field of robotics. For example, one robot manufacturer may write a command to linearly move a robot from one point or position to another as “MoveL toPoint1, speed100, zone1, tool1;” and a different manufacturer as “PTP P1 CONT Vel=100% PDATA1”. Each language is meant to be readable by an experienced programmer who may, using that language, reasonably write and test a program to do the job at hand. There are software tools for each particular language that help the user with the proper syntax and semantics so that the program can be loaded into the robot controller without errors.
One major issue with current control programming is that it requires detailed knowledge of both the particular control language in use and the process in which the controlled device is used. Thus, with current control programming techniques, the programmer must be an expert at both the particular control language and the process in which the controlled device is used. This is especially true for programming a robot, such as an industrial robot manipulator.
For each make of robot, even users with a low knowledge level must learn a new language in order to update or alter a robot program. Robot manufacturers have resisted making a common language for industrial robots in the belief that they would be limited in their ability to implement new features and would lose their competitive advantage. Also, solutions that localize the robot language to the user's native language do not address the fundamental problem that the user must still learn the robot language, even if some of the words are in his native tongue. What has not been addressed is the user's need to create a program using words and phrases familiar to him and common in his particular process or industry.
Another major issue with current robot programming is that teaching the robot the process path can be a tedious and complex task. The experience of the particular user who is teaching the robot the path is a large factor in obtaining a good result, and re-teaching is needed whenever the manufacturing conditions or environments change. Also, the process may require large numbers of path points for complex curves, a process path accuracy that is difficult for an operator to achieve by hand, and other special process specific issues such as strict tool orientation requirements that an operator may have difficulty programming. In many cases, Computer Aided Design (CAD) models for the workpiece are not available, which prevents off-line teaching of complicated paths in one of the various robotics simulation packages available on the marketplace. Thus the user is left with hours or even weeks of path teaching time when programming very complicated parts or processes.
Additionally, robot programs themselves have been criticized for being obtuse and written according to the whims and knowledge level of the particular programmer. Often a program will have procedure calls and logic whose purpose is not apparent to a programmer who may be required to troubleshoot or add to an existing program. The structure of the program itself may not be consistent even between two robots performing the same process. Too often, the new programmer finds it quicker to rewrite the entire program rather than try to understand and improve on the existing one.
In an attempt to make robot programming more user friendly, several graphic programming methods have been proposed and/or developed. One such method is utilized by the LEGO® Mindstorms robot system. Another such system is described in “The MORPHA Style Guide for Icon-Based Programming”. These types of graphic programming methods have a flowchart form and utilize standard icons. Such programming methods have met with limited success in complex robotic applications because of the difficulty in developing a complex program using standard icons. Common parts of even a simple robot routine, such as an error handler, can be difficult to graphically program in a simple and direct manner. Moreover, the standard icons may not be very descriptive and may require a programmer to be intimately familiar with the symbology of the graphical programming language. As a result, flowchart-type graphical programs can be even more difficult to understand than conventional code programs. In addition, flowchart-type graphical programming is primarily focused on graphically representing a robot program, rather than facilitating proper and/or more efficient robot programming.
There are several other aspects of robot programming that are not addressed in current industrial robot programming methodologies. One such aspect is information about the robot program and program data. For example, with current programming technology, it is not possible to know if position data in a move command has been taught, should be taught, or if it has been tested. Also, currently it is not possible to know how different lines or sections of a program are related to each other. There is no method of grouping together related parts of the program to give the sections the appropriate context and to state what a particular part of a program is trying to accomplish.
Another unresolved area in current robot programming methodologies is the separation of the process to be performed from the particular data of an installation. For example, two similar robot installations making the same part with the same tooling for the same customer, but used by two different companies, will often have unrelated programs, since each robot was programmed by a different programmer. With current robot programming practices, the data pertinent to the particular installation is entwined with the data that is common to the process in general. Both robots are performing the same process in both installations, but the particular positions they move to and the particular inputs they read and outputs they set are different. What is needed is a method to separate the common process data, which determines what the robot should do and in what order, from the particular data unique to the installation, such as the actual location of the ‘home’ position.
Another need not addressed in current robot programming methodologies is the need to organize the overall structure of the robot programs. Previous attempts to standardize robot programs have met with limited success since they either sacrificed flexibility for commonality by enforcing a strict structure, or they merely left open spaces in the standard program for users to insert code to fit their unique needs. What has not been previously provided is structure, and a method for the programmer to take advantage of that structure, which allows him complete flexibility, yet enables the programmer to make standard programs that may be used in multiple installations.
Another need not solved in current robot programming methodologies is the ability to embed within the robot program the knowledge of how to accomplish a particular process. In current practice, it is the programmer that must have the requisite knowledge and experience about a particular process in order to properly program the robot installation. The programmer is not assisted by the robot in any way because the robot itself has no knowledge about how to accomplish the process. Thus there is a need for an embedded data structure that can contain the sequences and process parameters necessary to accomplish a certain process and a methodology that enables the robot itself to guide the user through the programming process.
The apparatus and method of the present invention are directed toward improving the foregoing aspects of conventional control programming (and in particular, robot programming).